feat: add pg-search container image - #13
Conversation
Signed-off-by: Philippe Noël <philippemnoel@gmail.com>
|
Thanks for this! It motivated me to actually get this project production ready. I spent a ton of time over the past couple days cleaning things up. I think I've fixed all the branding (the original name "Not CNPG" was a funny reference to the licensing issue, but this name "CNPG Extensions" is much more professional). But more importantly, I'm pretty sure that I now have all of the CI working - renovate and the OS dependency checker are watching for any updates to packages or their dependencies, and trigger automatic updates here. I also set up a local artifacts repository and got the Extension Catalog working. The catalog here in CNPG Extensions is layered on top of the official CloudNativePG extension catalog. That means that users can simply update their catalog to point here instead of CNPG and they will have a full catalog of auto-updating extensions including both everything here and everything official. Catalogs are updated once a week and pull in all updates from upstream. Refactored tests with a very minimal change to the dagger code so that we dont need stubs anymore - since we have catalogs, realized we can leverage them to solve this more cleanly. Everything has minimal change so that I can continue to track upstream cloudnative-pg extension container repo and merge updates to CI. I've also contributed a few fixes I found upstream. For pg_search, two things off the top of my head. First, we can remove the pgvector stub - shouldn't need it anymore with the updates. Second, I'd like to scrutinize how dependencies are handled a bit. I want to make sure that we have clear provenance, that it's transparent how the binary is being built and what version of every dep are used, and I want to make sure that updates to dependencies reliably trigger rebuilds. Separately I'm looking into pg_parquet which is another rust-based postgres extension. I'm kinda interested to spend a little time researching if there might be a better way to containerize a rust-based postgres extension. Debian packages that run on the official Debian build infra have very strong dependency management (they scan binaries for function references). Is pg_search producing dynamically linked libraries? Are we reliably detecting shared library dependencies? Are there any? |
54d2c5b to
0645639
Compare
2 participants
Extension
Adds a CloudNativePG extension image for ParadeDB's
pg_searchextension, based on ParadeDB's existingdocker/Dockerfile.extension. The image supports PostgreSQL 18 on Debian Bookworm and Trixie for amd64 and arm64.The image:
.debwith per-platform SHA-256 verification;pg_search.so, control/SQL files, and license notices in aFROM scratchpayload;/system;shared_preload_librariesandld_library_pathmetadata;vectorextension resolves during E2E testing; andCloses #14
Contributor checklist
feat: add ...format.main.metadata.hclrecords package/catalog version 0.25.6 and the required runtime configuration.create_extension = truematches the packagedpg_search.control.FROM scratch, uses UID/GID 65532, and contains only extension artifacts, required linked libraries, and licenses.Validation
git diff --checkpg_search.so, extension SQL/control files,libopenblas.so.0,libgfortran.so.5, and corresponding noticesThe repository bake definitions parse both new metadata files and expand their complete Bookworm/Trixie matrix. Local
buildx bake --checkreached export, then hit a local-driver limitation for index annotations; direct representative builds passed.